home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001228_weber@eitech.com _Tue Jun 1 21:37:30 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <weber@eitech.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA04634; Tue, 1 Jun 93 21:37:30 MET DST
  4. Received: from lks.lks.csi.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA18307; Tue, 1 Jun 1993 21:59:02 +0200
  6. Received: from eitech.eitech.com by lks.lks.csi.com (5.65/6.930123)
  7.      with SMTP id AA25050; Tue, 1 Jun 93 14:57:47 -0500
  8. Received: from bd.eitech.com ([192.100.58.27]) by eitech.com (4.1/SMI-4.1)
  9.     id AA05939; Tue, 1 Jun 93 12:53:47 PDT
  10. Message-Id: <9306011953.AA05939@eitech.com>
  11. X-Sender: weber@eitech
  12. Date: Tue, 01 Jun 1993 12:59:32 -0800
  13. To: www-talk@nxoc01.cern.ch
  14. From: weber@eitech.com (Jay Weber)
  15. Subject: HTTP ACCEPT field and MIME types
  16. X-Mailer: <PC Eudora Version 1.1a5>
  17.  
  18. I was looking through a draft HTTP 2.0 spec (may be as old as 7-Dec-92)
  19. and noticed a potential problem with the ACCEPT request field.  One puts
  20. a comma-separated list of MIME types as the field value.  The problem is
  21. that MIME types can involve parameters, and some parameters may be
  22. crucial to a client's acceptance of the type.  For example, an old
  23. example from the MIME spec is:
  24.  
  25.                  Content-Type:  application/octet-stream;
  26.                       name=foo.tar.Z; type=tar;
  27.                       conversions="x-encrypt,x-compress"
  28.  
  29. This example is extreme, since application/octet-stream is usually a
  30. no-brainer for clients, but the presence of these parameters makes it
  31. pretty UNIX specific.  You can image other examples, such as a "lossiness"
  32. parameter on image/jpeg, that would impact portability of the type.
  33.  
  34. Anyway, if we include parameters in MIME typing, then a comma-separated
  35. syntax doesn't work too well.  An easy fix would be to allow multiple
  36. ACCEPT fields in the header, with one MIME type per field.  I don't see
  37. an HTTP stance on multiple fields, and this treatment of multiple
  38. fields would be consistent with RFC 822 (the To: field, for example).
  39. How about it (Tim)?
  40.  
  41. In general, HTTP 2.0 is pretty cool.  Is an RFC coming soon (or here)?
  42.  
  43. Jay Weber
  44. EIT
  45.